The New Minimum Elements Standard for SBOMs

In July 2018, the great Dr. Allan Friedman [then working for the National Telecommunications and Information Administration (NTIA) in the Department of Commerce] started an industry working group devoted to defining what needed to be included in a machine-readable list of software components that had been utilized in a product called a software bill of materials (SBOM). These SBOMs could be used by consumers of a product to determine if the product contained software components that had known vulnerabilities. Thus, allowing them to determine their own level of “risk tolerance” for a given product.

This working group had some amazing experts who regularly contributed to this goal. I was fortunate enough to be included from the first day. However, we all brought pre-established views and opinions about all aspects of SBOM definition and use to our participation.

Fortunately, Dr. Friedman was a master at “herding cats.” He kept all the experts focused on the goal and did not allow them to get lost in pet peeves or distracted by “shiny things.” Every meeting, there were many subtopics that either needed to be addressed, rejected, or put aside for later. None of the members (me included) had a clue as to how big this subject was going to become.

We met weekly (at times, even more frequently) and explored this subject in great detail, resulting in documents being released to the public to assist them in dealing with SBOMs.

The Minimum Elements Document

Fast-forward to 2021, when a series of significant events occurred. 

• Executive Order (EO) 14028 was released by the Biden White House, which mandated that NTIA define what minimum elements needed to be included to be considered a valid SBOM.
• This EO also transferred the enforcement of SBOMs to the Cybersecurity and Infrastructure Security Agency (CISA), a part of the Department of Homeland Security.
• Dr. Friedman moved from a position with NTIA to one with CISA, and the working groups (by that time, there were several sub-groups) went with him.

Before leaving NTIA, Dr. Friedman used the work these groups had completed to serve as the basis for NTIA’s “Minimum Elements for a Software Bill of Materials” document the EO mandated. The working group participants were happy, as our work had come to the attention of the White House and was codified in this document.

For five years, the 2021 “Minimum Elements” document served as the common reference point for the contents of an SBOM. It was used by many industries, both foreign and domestic. Companies and tools were built to align with this document, not the least of which was the FDA. The agency had been one of the original stakeholders and driving forces in initiating the effort in 2018. The FDA added additional context in the form of how a component was supported but essentially adhered to the standard.

From product launches to M&A and manufacturing trends, the MPO Source delivers the medtech news you need twice a week. Subscribe here!

A New International Document

In his role at CISA, Dr. Friedman continued using working groups to clarify supply chain and SBOM topics; however, the halcyon days of the NTIA group were over. The CISA working groups had been demoted to not defining anything; rather, we were highlighting issues and offering possible solutions. However, none of this effort would result in determining CISA activity or any further standards.

In July 2025, due to Trump’s destruction of the federal workforce and a deep gutting of CISA personnel, as well as the cybersecurity protections that went with them, Dr. Friedman left CISA. As a result, the potential for industry input into SBOMs evaporated.

A year later, CISA joined 16 international partner agencies and, with input from the European Commission, published a substantial update that replaced the NTIA document. Note that no industries that would be affected by producing or consuming SBOMs were involved in the effort. Their omission may be responsible for some of the more unworkable changes in the 2026 “Minimum Elements” standard.

The revision keeps the original three-part structure of data fields, automation support, and practices and processes, but it expands the mandatory data set, sharpens ambiguous language, and raises the bar for what it means to deliver a complete SBOM. For medical device developers operating under FDA cybersecurity expectations and the EU Cyber Resilience Act, these changes may not be academic. They have the potential to reshape what a compliant SBOM looks like and what tooling and processes will be needed to produce one.

Comparing Documents: 2021 vs. 2026

During the last five years, the worldwide adoption of SBOMs has been staggering. Whenever we talk about the quantity of SBOMs being monitored or ingested, the numbers have ballooned into the millions. SBOMs are now generated at scale, written into customer requirements, and fed into automated security processes. As a result, you would have thought the SBOM ecosystem would have also matured, but, for the most part, this is not the case, especially in the medical device industry. 

The NTIA document, issued under Executive Order 14028, was deliberately modest. Its goal was not to define the perfect SBOM but to establish a practical floor. The intent was to create something industries could begin to adopt, both as a producer and a consumer of SBOMs. There was a significant “chicken and egg” problem here, so something had to be done to break this logjam.

That 2021 baseline defined seven data fields: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp. It called for automation support through three named formats: SPDX, CycloneDX, and SWID tags. It also defined six practices and processes: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

Crucially, the 2021 depth requirement was forgiving. It said an SBOM should list top-level components with enough detail to seek out transitive dependencies, but enumerating only the first layer of dependencies was explicitly deemed sufficient. Hashes, licenses, and digital signatures were discussed only as recommended or aspirational fields, not requirements. The document repeatedly stressed tolerance for error and incompleteness because the ecosystem was young and we were trying to encourage the adoption of authoring SBOMs. And the most significant point: this was being defined by people who actually worked with SBOMs and understood what was and what wasn’t possible.

The single most visible change in the 2026 document was the growth in required fields. It added 10 new elements. On the document side, these were the SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, and SBOM Version. On the component side, the new required fields were Component Hash Value, Component Hash Algorithm, and Component License. Several existing elements were also pointlessly renamed and clarified. Supplier Name became Component Producer, Other Unique Identifiers became Component Identifiers, Version of the Component became Component Version, and Author of SBOM Data became SBOM Author. Where the 2021 baseline had seven component-and-metadata fields, the 2026 appendix lists 17.

This means capabilities the NTIA document treated as optional or future work, notably cryptographic hashes and license identifiers, were now part of the baseline. Hashes moved from a recommended field to two required fields, a value and an explicitly named algorithm with prescriptive guidance to use IANA hash function names and NIST-approved algorithms. Licenses, once discussed only under “beyond minimum elements,” were now required, with a preference for machine-readable SPDX license identifiers.

The change in depth was arguably the biggest revision of all; this replaced a single layer of dependencies with a full depth of dependencies being mandated. An SBOM should now account for all components that make up the target software, including transitive dependencies, with no minimum depth. Good luck finding a tool that will always achieve this.

Additional Insights on the New Document

The 2026 document allows linked SBOMs rather than one enormous file, provided the recipient can access the complete set, but the intent is obviously that an SBOM should describe all the software components. The document sets a demanding functional test: a recipient should be able to conclude a newly reported vulnerability does not affect them if the SBOM does not list the associated component. Absence from the SBOM is meant to become meaningful evidence.

This is where it becomes obvious that only regulators wrote this new document, with no impacted industries being included. That one statement: “…vulnerability does not affect them if the SBOM does not list the associated component.” Whether your product is affected requires more than just the presence or absence of a component in the SBOM. This is why the VEX format exists.

The new document defined the 2021 version’s “Known Unknowns” as “Explicitly Identifying Unknown Information” (that just rolls off the tongue). Authors must now distinguish between data they genuinely do not know and data they know but intentionally withhold. Why CISA thought this was important is beyond me. If the information isn’t there, the end user has no way to have further insights into what is in the product; the manufacturer’s motive for excluding this information is pointless. This feels like a lawyer was involved.

Three additions strengthen trust and traceability. The SBOM Author Signature provides a digital signature so a recipient can confirm the document was not altered after signing. The SBOM Tool Name and Version record how the SBOM was produced. The SBOM Generation Context captures the lifecycle phase, such as “before build,” “build,” or “after build,” at which the SBOM was generated, because an SBOM built from source can differ materially from one derived through binary analysis. These additions come with caveats worth keeping in mind. An author signature only proves that someone signed the document, not that the SBOM is accurate or complete. Also, generation context still lacks a controlled vocabulary, which will limit its usefulness to automated tooling until further implementation work is completed. 

SWID tags have been removed from the list of accepted formats, leaving SPDX and CycloneDX as the two widely used, open, machine-processable formats. This is a formal recognition, catching up with what the marketplace had already decided, which is that no one uses SWID tags. This is a good change, but largely unnecessary.

Why Medtech Should Care

Medical device manufacturers sit at the intersection of the trends driving this update. FDA premarket cybersecurity expectations already require an SBOM for cyber devices, and the EU Cyber Resilience Act requires an SBOM as part of technical documentation for products with digital elements. The open question across the device community is when and how regulators, the FDA in particular, will align their expectations with the new baseline. That question captures the practical stakes. Given how poorly SBOMs have been handled over the last five years and the capabilities of current SBOM tooling, trying to align FDA expectations with this new document will be problematic.

Requiring a verified hash and a generation context pushes SBOM generation closer to the build pipeline. A hash should only be included when the author had access to the artifact and computed it, not copied it from upstream, which means SBOMs assembled purely from manifests or third-party data will fall short. For device developers, this favors generating SBOMs at build time and, where they rely on legacy or supplied binaries, using binary analysis while honestly recording the generation context. So, why did we originally make the hash optional? If you have a medical device with 100 to 10,000 software components in it, who is going to be using this data? At what stage in the post-market phase does having this make sense? It seems like a good idea but doesn’t really have a valid use case.

Making License Identifiers a required field means device software teams must track open-source license data as a matter of course. License information is not a security concern, and a license field is not, by itself, proof of compliance. While there might be some practical value to the manufacturer, this has nothing to do with cybersecurity. Either of the two SBOM formats has always supported license information, but the utilization of this field should be up to each manufacturer, and it has no value to the end users.

The added SBOM Version, Timestamp discipline, and Author Signature align well with the change-control and traceability expectations already familiar in medical device quality systems. Each new build or correction should yield a new, versioned SBOM. Manufacturers accustomed to design history files and configuration management will find these requirements natural, though they add record-keeping overhead and require integrating SBOM versioning into existing release processes. Much like a hash, this seems like a positive, but what is the use case where this improves cybersecurity?

Conclusion

I would much rather have kept the 2021 original document and pushed for better support and implementation within the industry. Some of the things that should have been included are forks, patches, and derivation relationships. This is exactly what you would expect a group of non-industry regulators to create: significantly more work for very little improvement.

The safe course of action for a manufacturer is to build SBOM generation into the build pipeline now (it should already be there), capture hashes and licenses, pursue full transitive coverage with explicit handling of unknowns, and watch closely for the FDA and EU guidance that could translate this voluntary baseline into concrete regulatory expectations. In the meantime, becoming compliant with the original 2021 minimum element document for SBOMs is challenging enough.

More from this author: The Butterfly Effect of AI on Cybersecurity

Christopher Gates is the founder and CEO of arsMedSecurity, a medtech cybersecurity consulting firm. He is a recognized thought leader in medical device cybersecurity and the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, and Bluetooth SIG.